Re: IP Layer 2 Transport over L2TPv3

Circa 9/28/2005 11:51 PM, Prasad Yadati said the following:
> Hi Carlos,
> 
> Carlos Pignataro wrote:
> 
>> Hi Prasad,
>>
>> Circa 9/23/2005 8:00 AM, Prasad Yadati said the following:
>>
>>> Hi Carlos,
>>>
>>> Please see in-line.
>>>
>>> Carlos Pignataro wrote:
>>>
>>>
>>>> Hi Prasad,
>>>>
>>>> Please see inline.
>>>>
>>>> Circa 9/20/2005 7:01 AM, Prasad Yadati said the following:
>>>>
>>>>
>>>>> Carlos,
>>>>>
>>>>> Please see in-line.
>>>>>
>>>>> Carlos Pignataro wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Prasad,
>>>>>>
>>>>>> Thanks. Please see a couple of comments inline.
>>>>>>
>>>>>> List,
>>>>>>
>>>>>> Any further comments on the request to accept this draft as a working
>>>>>> group document?
>>>>>>
>>>>>>
>>>>>> Circa 9/17/2005 5:50 AM, Prasad Yadati said the following:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Good one Carlos.
>>>>>>> How about just specifying it as "IP transport over L2TPv3".
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> The "IP Layer 2" was added there for 2 reasons:
>>>>>> 1. To somehow differentiate raw-IP from framed-IP being transported
>>>>>> over
>>>>>>  L2TPv3 while trying to reference the NSP function that interfaces
>>>>>> the
>>>>>>  L2 AC with the IP PW Termination.
>>>>>> 2. Symmetry/parity name with the already defined PW Type for MPLS
>>>>>> PWE3.
>>>>>>
>>>>>
>>>>> But as per this draft, no "IP layer 2" information is transported.
>>>>
>>>>
>>>>
>>>>
>>>> Yes, only IP datagrams are transported, although there is a Layer 2
>>>> attachment circuit, and hence "IP Layer 2". The NSP function "extracts
>>>
>>>
>>>
>>> Attachment circuit layer 2 is already terminated. Isn't it ? L2TPv3 in
>>> this case does not aware of attachment circuit's layer 2. In fact it
>>> does not matter what kind of layer 2 IP was carried at the attachment
>>> circuit.
>>> I am sorry Corlos, I am still not clear.
>>
>>
>>
>> Although the "IP Layer 2" was intended to make the NSP function
>> explicit, I understand (and agree on second thoughts) the argument that
>> can be confusing with what's actually being transported.
>>
>> How about this to describe the main aspects of the draft:
>> "Signaling and Encapsulation for the Transport of IP over L2TPv3"
> 
> 
> Looks good to me, Carlos.
> 
>>
>> There are also two further items in the draft to possibly update:
>> 1. "IP Layer 2 interface": I'd leave this one as is.
> 
> Carlos, why not we just use AC (attachment circuit) instead, so that it
> will be consistent with rest of the L2TPv3 RFCs.
> 

Yes, AC is already used.

>> 2. PW Type/PW name: If changing the title, I'd also update:
>>     IPL2PW IP Layer 2 Transport Pseudowires
>>     IP Layer 2 Transport Pseudowire Type.
>>    to:
>>     IPPW   IP Transport Pseudowires
>>     IP Transport Pseudowire Type.
> 
> 
> Looks good.
> 
> Thanks a lot for taking care of the comments Carlos.

Thank you for the comments.

Regards,

--Carlos.

> 
> Regards
> Prasad
> 
>>
>> Would this aid in clarity?
>>
>> Thanks for your comments !
>>
>> --Carlos.
>>
>>
>>>> IP datagrams from the Layer 2 frames" and that's the motivation for the
>>>> name, make a distinction from framed-IP. See below as well.
>>>>
>>>>
>>>>
>>>>> Rather we are trying to prevent the same. For me, "IP layer 2"
>>>>> seems to
>>>>> be mis-leading.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> "IP transport" may possibly be too generic for the procedures
>>>>>> defined.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Corlos, for me, "IP transport" seems more appropriate than current. In
>>>>> this case as far as L2TPv3 is concerned, it is transporting IP rather
>>>>> than layer 2 frame.
>>>>
>>>>
>>>>
>>>>
>>>> IMHO, "IP transport" is too generic, and does not fully convey what's
>>>> happening in the interface between the physical layer 2 interface and
>>>> the pseudowire termination. Other PW Types transport IP (framed-IP) as
>>>> well. I thought about "raw ip" and "native ip" but opted against them
>>>> for a similar reason. Any other suggestions?
>>>
>>>
>>>
>>> How about "Abstracted/Extracted IP over L2TPv3" ?
>>> If this draft can be, really generic, I mean if it  can be used even for
>>> non-pw cases where L2TPv3 carries generic IP datagrams, we may have "IP
>>> transport over L2TPv3" ?
>>>
>>> Kind Regards
>>> Prasad
>>>
>>>
>>>
>>>
>>>>
>>>>>>> Wondering whether we can have a generic "Layer 3 transport over
>>>>>>> L2TPv3"
>>>>>>> and specify transport of all layer 3 protocols (IP, IPX,....) in it
>>>>>>> including IP.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Do you mean multiple L3 protocols at the same time over the session?
>>>>>> I'd
>>>>>> think we can use existing L2 transports to accomplish that. OTOH,
>>>>>> IP as
>>>>>> L3 stands out in the applications of an "IP L2" session.
>>>>>
>>>>>
>>>>>
>>>>> Sorry I was not clear. I meant to combine specification of other
>>>>> layer 3
>>>>> data packets over L2TPv3 in one draft. May be that is not needed.
>>>>> We may
>>>>> have separate similar such of these drafts for other layer 3
>>>>> protocols.
>>>>> Please ignore this comment.
>>>>
>>>>
>>>>
>>>>
>>>> OK. Thanks,
>>>>
>>>> --Carlos.
>>>>
>>>>
>>>>
>>>>> Thanks
>>>>> Prasad
>>>>>
>>>>>
>>>>>
>>>>>> Thanks !
>>>>>>
>>>>>> --Carlos.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Regards
>>>>>>> Prasad
>>>>>>>
>>>>>>> Carlos Pignataro wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> We submitted the following `IP Layer 2 Transport over L2TPv3'
>>>>>>>> draft:
>>>>>>>> http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg06623.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> that details the tunneling of IP datagrams directly over an L2TPv3
>>>>>>>> session, and defines the `CE IP Address AVP' as well.
>>>>>>>>
>>>>>>>> We would like it to become an l2tpext working group document, and
>>>>>>>> seek
>>>>>>>> review, feedback and comments from the WG.
>>>>>>>> So we ask here for the draft to be accepted as work item for the
>>>>>>>> group.
>>>>>>>> Your feedback will be most appreciated.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>
>>
> 

-- 
--Carlos.
Escalation RTP - cisco Systems