Re: [mpls-tp] Internal inconsistencyindraft-ietf-mpls-tp-framework-06

[Alexander Vainshtein <[e-mail]>]

Yuanlong,
Lots of thanks for a prompt response.

The approach you've taken makes sense to me.
However, please note that:
1.   actual format of ARP mediation messages in the SCC and ARP mediation protocol itself
      over SCC have tobe redefined
2. Service traffic (IP) would only start running across an MPLS-TP domain after ARP mediation is completed
3. Known limitations of the ARP mediation draft probably apply "as is" to this case
4. the PW label will NOT be used as the payload type discriminator.

Regards,
     Sasha

> -----Original Message-----
> From: Jiang Yuan-long [mailto:[e-mail]] 
> Sent: Wednesday, October 28, 2009 2:10 PM
> To: Alexander Vainshtein
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Internal 
> inconsistencyindraft-ietf-mpls-tp-framework-06
> 
> Sasha, please see my comments in-line.
> 
> Regards
> Yuanlong
> 
> ----- Original Message ----- 
> From: "Alexander Vainshtein" <[e-mail]>
> To: "Jiang Yuan-long" <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, October 28, 2009 7:27 PM
> Subject: RE: [mpls-tp] Internal 
> inconsistencyindraft-ietf-mpls-tp-framework-06
> 
> 
> Yuanlong,
> Lots of thanks for a prompt response.
> 
> However, I am not sure what exactly the quoted statement from 
> the framework 
> draft means:
> - Are various protocols that accompany IP on different links 
> (ARP, InvARP, 
> IPCP etc.) considered to be part of the client service?
> [JYL] I don't think so. These protocols should be terminated 
> on the local 
> PE, rather than transported accross the network, as
> shown in the arp-mediation draft. The necessary info. such as 
> IP address 
> should be notified across the SCC channel which is defined in 
> draft-ietf-mpls-tp-gach-dcn.
> 
> - What happens if the links at two sides of a P2P IP service 
> (let's start 
> from the simplest use case) are different?
>   E.g., IP over Ethernet vs. IP over PPP?
> [JYL] Similar to the above, both end PEs should terminate its 
> local client's 
> control protocols such as Ethernet or PPP.
> 
> Regards,
>      Sasha
> 
> > -----Original Message-----
> > From: Jiang Yuan-long [mailto:[e-mail]]
> > Sent: Wednesday, October 28, 2009 12:46 PM
> > To: Alexander Vainshtein; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [mpls-tp] Internal
> > inconsistencyindraft-ietf-mpls-tp-framework-06
> >
> > Sasha,
> >
> > I think the scenario as you described is covered in Sec. 3.4.1 of
> > draft-ietf-mpls-tp-framework-06,
> > which says:" When providing...IPLS,  pseudowires MUST be used
> > to carry the
> > client service."
> >
> > Regards
> > Yuanlong
> >
> > ----- Original Message ----- 
> > From: "Alexander Vainshtein" <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>; 
> <[e-mail]>
> > Sent: Wednesday, October 28, 2009 4:37 PM
> > Subject: Re: [mpls-tp] Internal
> > inconsistencyindraft-ietf-mpls-tp-framework-06
> >
> >
> > > Stewart and all,
> > > Do I read that correctly that if I want to run IP traffic
> > in MPLS-TP I
> > > have to use at least two different encapsulation labels:
> > > - one to identify IP traffic proper
> > > - another to identify whatever accompanying protocols (ARP,
> > IPCP, InvARP
> > > etc.) are used?
> > >
> > > What is going to happen if native IP uses different Layer 2
> > techniques at
> > > different ends of such a tunnel?
> > >
> > > In MPLS this is known as "ARP mediation" and discussed in 
> detail in
> > > draft-ietf-l2vpn-arp-mediation.
> > > I believe that the problem that this draft tries to resolve
> > is equally
> > > valid for MPLS-TP, but a new toolset is required.
> > >
> > > My 2c,
> > >     Sasha
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: [e-mail]
> > >> [mailto:[e-mail]] On Behalf Of Stewart Bryant
> > >> Sent: Wednesday, October 28, 2009 1:40 AM
> > >> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> > >> Cc: [e-mail]; [e-mail]
> > >> Subject: Re: [mpls-tp] Internal
> > >> inconsistencyindraft-ietf-mpls-tp-framework-06
> > >>
> > >> If it's ONLY IP then no, but IP often comes with support
> > >> protocols, in which case you need a protocol identifier.
> > >> However it's also useful to have a service identifier label
> > >> and the text says "Note that the functions of the Encap label
> > >> and the Service Label may represented by a single label"
> > >>
> > >> - Stewart
> > >>
> > >>
> > >>
> > >> Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> > >> >
> > >> > Stewart,
> > >> >
> > >> > Do we need the protocol label if we use the entire LSP
> > only for IP
> > >> > traffic?
> > >> >
> > >> > Best regards,
> > >> >
> > >> > Nurit
> > >> >
> > >> >
> > >> >
> > >> >
> > >> --------------------------------------------------------------
> > >> ----------
> > >> >
> > >> > *From:* [e-mail]
> > >> [mailto:[e-mail]] *On
> > >> > Behalf Of *ext Stewart Bryant
> > >> > *Sent:* Tuesday, October 27, 2009 11:42 PM
> > >> > *To:* Drake, John E
> > >> > *Cc:* [e-mail];
> > [e-mail]
> > >> > *Subject:* Re: [mpls-tp] Internal
> > >> > inconsistencyindraft-ietf-mpls-tp-framework-06
> > >> >
> > >> >
> > >> >
> > >> > Would it help is we said earlier
> > >> >
> > >> >
> > >> > > >   This document specifies the architecture for two
> > >> types of client
> > >> > > >   adaptation:
> > >> > > >
> > >> > > >   o  A PW
> > >> > > >   o  An MPLS Label used to identify a network 
> layer protocol
> > >> >          such as IP or MPLS.
> > >> >
> > >> > Then use "Lou's New text".
> > >> >
> > >> > - Stewart
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Drake, John E wrote:
> > >> >
> > >> > Andy,
> > >> >
> > >> > The MPLS label under discussion is the label at the bottom
> > >> of the MPLS TP server stack, which identifies the client
> > >> network layer protocol.  The client network layer protocol
> > >> can be IP, MPLS, etc.
> > >> >
> > >> > So, Lou's formulation is correct, although the distinction
> > >> between an L1/L2 client using a pseudo-wire adaptation and an
> > >> L3 client using an MPLS label adaptation is not made until
> > >> you get to the sections themselves.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > John
> > >> >
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: [e-mail] 
> <mailto:[e-mail]>
> > >> >> [mailto:[e-mail]] On Behalf Of Andrew G. Malis
> > >> >> Sent: Tuesday, October 27, 2009 11:00 AM
> > >> >> To: Lou Berger
> > >> >> Cc: [e-mail]
> > >> <mailto:[e-mail]>;
> > >> [e-mail] <mailto:[e-mail]>
> > >> >> Subject: Re: [mpls-tp] Internal inconsistency
> > >> >> indraft-ietf-mpls-tp-framework-06
> > >> >>
> > >> >> Lou,
> > >> >>
> > >> >> Actually, that's better, but just part-way there. Since IP is
> > >> >> specificallly discussed in section 3.4.2, your second
> > >> >> sentence should probably read:
> > >> >>
> > >> >>
> > >> >>>   When the client adaptation is via a PW, the
> > >> >>>   mechanisms described in Section 3.4.1 are used.
> > >> >>>   When the client adaptation is via a MPLS label or
> > >> >>>    a network layer protocol such as IP, the
> > >> >>>   mechanisms described in Section 3.4.2 are used.
> > >> >>>
> > >> >> Cheers,
> > >> >> Andy
> > >> >>
> > >> >> On Tue, Oct 27, 2009 at 12:51 PM, Lou Berger
> > >> <[e-mail]> <mailto:[e-mail]> wrote:
> > >> >>
> > >> >>> Andy,
> > >> >>>        The latest text reads:
> > >> >>>   3.4. MPLS-TP Client Adaptation
> > >> >>>
> > >> >>>   This document specifies the architecture for two
> > types of client
> > >> >>>   adaptation:
> > >> >>>
> > >> >>>   o  A PW
> > >> >>>   o  An MPLS Label
> > >> >>>
> > >> >>> So the text has been fixed to address adaptation layers
> > >> for clients
> > >> >>> rather than the clients themselves.  I've also asked
> > >> >>>
> > >> >> (privately) for
> > >> >>
> > >> >>> the following change:
> > >> >>> OLD:
> > >> >>>   When the client is a PW, the MPLS-TP client
> > adaptation functions
> > >> >>>   include the PW encapsulation mechanisms, including the
> > >> PW control
> > >> >>>   word.  When the client is operating at the network 
> layer the
> > >> >>>   mechanism described in Section 3.4.2 is used.
> > >> >>> NEW:
> > >> >>>   When the client adaptation is via a PW, the
> > >> >>>   mechanisms described in Section 3.4.1 are used.
> > >> >>>   When the client adaptation is via a MPLS label, the
> > >> >>>   mechanisms described in Section 3.4.2 are used.
> > >> >>>
> > >> >>> Which, I believe, should address the rest of your comment.
> > >> >>>
> > >> >>> Lou
> > >> >>>
> > >> >>> On 10/27/2009 11:02 AM, Andrew G. Malis wrote:
> > >> >>>
> > >> >>>> Following Rahul's talk at the MPLS conference, he and I
> > >> >>>>
> > >> >> discovered an
> > >> >>
> > >> >>>> internal inconsistency in
> > >> draft-ietf-mpls-tp-framework-06, section
> > >> >>>> 3.4. That section only lists MPLS labels and PWs as 
> clients to
> > >> >>>> MPLS-TP, but the text in section 3.4.2 clearly
> > includes IP as a
> > >> >>>> client as well. We suggest including IP to the list in
> > >> section 3.4.
> > >> >>>>
> > >> >>>> Thanks,
> > >> >>>> Andy
> > >> >>>> _______________________________________________
> > >> >>>> mpls-tp mailing list
> > >> >>>> [e-mail] <mailto:[e-mail]>
> > >> >>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >> _______________________________________________
> > >> >> mpls-tp mailing list
> > >> >> [e-mail] <mailto:[e-mail]>
> > >> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> > >> >>
> > >> >>
> > >> > _______________________________________________
> > >> > mpls-tp mailing list
> > >> > [e-mail] <mailto:[e-mail]>
> > >> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >> _______________________________________________
> > >> mpls-tp mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/mpls-tp
> > >>
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> > = 
> 
>