Subject: RE: Query on draft-ietf-mpls-label-encaps

From: Shahram Davari <[email-masked]>
Date: Sun, 15 Oct 2000 10:10:40 -0700

Hi Curtis,

Although you are right in saying that L3PID could determine the L3, but this
is limited only to REVP-TE. CR-LDP does not have such a field in its label
request, and besides this is not required by label-encaps draft.

So I think that the current IPV4/IPV6 explicit null labels are needed to
addresses the scenarios in which L3PID does not exist (such as CR-LDP case).

Regards,
-Shahram

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Wednesday, October 11, 2000 11:55 PM
> To: Sudhanshu Jain
> Cc: [email-masked]; Yakov Rekhter; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Query on draft-ietf-mpls-label-encaps 
> 
> 
> 
> In message 
> <[email-masked]>, "Sudhanshu Jain"
>  writes:
> > This is a multi-part message in MIME format.
> > 
> > ------=_NextPart_000_0188_01C033BC.4D01B680
> > Content-Type: text/plain;
> > 	charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > Hi All,
> >    In draft-ietf-mpls-label-encaps-08.txt, in section 2.1 
> language has =
> > been
> >    changed to ....
> > 
> >               i. A value of 0 represents the "IPv4 Explicit 
> NULL Label".
> >                  This label value is only legal at the bottom of the
> >                  label stack.  It indicates that the label 
> stack must be
> >                  popped, and the forwarding of the packet 
> must then be
> >                  based on the IPv4 header.
> > 
> > 
> >    From draft-ietf-mpls-label-encaps-07.txt, in section 2.1 ....
> > 
> >               i. A value of 0 represents the "IPv4 Explicit 
> NULL Label".
> >                  This label value is only legal when it is the sole
> >                  label stack entry.  It indicates that the 
> label stack
> >                  must be popped, and the forwarding of the 
> packet must
> >                  then be based on the IPv4 header.
> > 
> >  =20
> >   Same stands for the bullet (iii).
> > 
> >   Does it mean, Label 0 and Label 2 are used to carry 
> Protocol type=20
> >   at the "bottom of the label stack" in case of tunnel traffic?=20
> > 
> >   Is it the standard way to carry the protocol type in MPLS Tunnel =
> > traffic?
> > 
> > Thanks,
> > -Sudhanshu
> 
> 
> Sudhanshu,
> 
> The last phrase in this paragraph should be reworded to say that it
> will be forwarded based on the protocol type specified in the L3PID
> when the tunnel was set, for example IPv4 or IPv6.
> 
> Note to authors:
> 
>   Remove the last the words, "on the IPv4 header" and replace with "on
>   the underlying payload's header".  You could also add a sentence
>   "The protocol type of the underlying header is determined by
>   signaling that occurs at LSP setup time".
> 
> The use of L3PID to determine payload protocol identifier is
> definitely a good candidate for an FAQ.  The signaling of L3PID is
> specified in section 4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-07.txt.
> 
> Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 16 Oct 2000 09:32:27 -0400

In message <9DC5E2ABE65BD54CA9088DA3194461D6010C99E6@BBY1EXM01>, Shahram Davari
> request, and besides this is not required by label-encaps draft.

Does anyone use CRLDP?  :-)

> addresses the scenarios in which L3PID does not exist (such as CR-LDP case).

CRLDP needs to get fixed to carry an L3PID.

Generalized MPLS has a G-PID which is redundant for RSVP but fixes the
CR-LDP problem.

Curtis