Subject: Re: [mpls-tp] MPLS-TP Protocol Type definition => is the GAL Header required in LSP OAM packets?

From: <[email-masked]>
Date: Thu, 29 Jan 2009 15:10:33 -0000

What I just said is not precise, my apologies.....please change this
sentence:

 "..and this also removes restrictions on what can follow the GAL in
future. "

to 

"..and this also removes restrictions on what can follow a header with
S=1 in future."

And if not clear why I say this it is to allow us the opportunity to
insert a special label in the DP to provide a proper MPLSoverMPLS
client/server relationship between 2 MPLS networks and therefore lets
each MPLS network to use the S bit independently in its own sublayer LSP
stack.

regards, Neil

> -----Original Message-----
> From: Harrison,N,Neil,CXM R 
> Sent: 29 January 2009 15:00
> To: 'Maarten Vissers'; [email-masked]
> Subject: RE: [mpls-tp] MPLS-TP Protocol Type definition => is 
> the GAL Header required in LSP OAM packets?
> 
> Maarten
> 
> Quick answer to your question from my perspective.....others 
> may have different reasons/views here.
> 
> I came to exactly the same conclusion some time ago, ie in 
> principle we do not need the GAL for OAM.  But what we do 
> need the GAL for is to indicate the OOB CP/MP server layer 
> 1-hop channel between logically adjacent MPLS-TP nodes.
> 
> But we can use the GAL for OAM indicate too (a "belt+braces" 
> means of ID).  It is not ideal because OAM now does not look 
> like traffic units, and it should do, ie traffic has 1 normal 
> forwarding header (S=1), OAM has 2 headers of GAL (S=1) and 
> normal forwarding header (S=0).  You may recall when I wrote 
> Y.1711 way back I hated the idea of a special label 14 for 
> 'OAM indicate' for exactly the reason noted above.  But then 
> I could not get access to any of the other bits in the 
> header, eg TTL field.....the OAM indicate flag should really 
> be part of the normal forwarding header.  
> 
> Now in MPLS-TP we do not need the TTL field for loop 
> mitigation (no co mode network needs a TTL) but I understand 
> we cannot touch this.  So I am happy to accept the compromise 
> of using the GAL here.  And a key reason I say this is 
> because in MPLS-TP we have no need to worry about the 1 
> nibble payload nonsense of ECMP as this cannot be allowed in 
> MPLS-TP.  In other words, whilst we can look at the 1st 
> nibble for 0001 (G-ACH) we do not have to....and this also 
> removes restrictions on what can follow the GAL in future.  
> But as I said above, the key value of the GAL IMO is to 
> provide the OOB CP/MP indication.
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Maarten Vissers
> > Sent: 29 January 2009 14:34
> > To: [email-masked]
> > Subject: [mpls-tp] MPLS-TP Protocol Type definition => is the GAL 
> > Header required in LSP OAM packets?
> > 
> > I have created a couple of slides to understand the MPLS-TP 
> Protocol 
> > Type definition and values. Refer to 
> > http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mpls-t
> > p-protocol-typ
> > es-00.ppt
> > 
> > MPLS-TP's protocol type information is carried inside a set 
> of fields 
> > (e.g.
> > S, 4-bit nibble, channel type, ...). It is possible to define in 
> > MPLS-TP standards MPLS-TP PW and LSP specific Protocol Type 
> values as 
> > combinations of specific values in those fields. Some examples are 
> > presented in slides
> > 8,9 and 11.
> > 
> > Looking at slides 10 and 11 (with MPLS-TP LSP Protocol Type 
> > definition), the question pops up what the added value of the GAL 
> > Header is in LSP OAM packets. It seems that the GAL Header 
> in LSP OAM 
> > packets is unnecessary from a protocol definition perspective. The 
> > G-AC Header (G-ACH) seems to contain sufficient typing information, 
> > which makes the GAL Header unnecessary in normal LSP OAM 
> packets. The 
> > GAL Header would only be required in Section LSP OAM packets when 
> > those are carried directly over a physical medium.
> > 
> > Removal of the GAL Header from LSP OAM packets will unite 
> the PW and 
> > LSP OAM packet formats into a signle MPLS-TP OAM packet format, 
> > removing the artificial difference between both types of 
> OAM packets 
> > in today's proposals.
> > 
> > What was the rationale to include such GAL Header in the LSP OAM 
> > packet format?
> > - A NNI port on a Provider (P) node not able to process MPLS-TP LSP 
> > OAM will have to pass through any such OAM packets.
> > - A NNI port on a Provider Edge (PE) node not able to 
> process MPLS-TP 
> > LSP OAM will have to discard any such OAM packets.
> > 
> > The NNI port on a PE node not able to process MPLS-TP LSP OAM may 
> > receive LSP packets of which the S-bit in the LSP label stack entry 
> > header has values 0 or 1.
> > A) S=0 implies that there is another LSE header in the packet and 
> > further processing is to be determined on the basis of the next LSE 
> > header's content.
> > B) S=1 implies that this is the bottom LSE header in the packet and 
> > further processing information has to be derived from the bits 
> > following this bottom of stack LSE header; e.g.
> > the 4-bits nibble following the TTL field indicates if the 
> packet is 
> > an IPv4 or IPv6 packet.
> > 
> > Under normal conditions, this NNI port will not receive any MPLS-TP 
> > LSP OAM packets when this port is not capable to process 
> such MPLS-TP 
> > LSP OAM packets. However under fault conditions (i.e. 
> misconnection), 
> > it is possble that a NNI port generating MPLS-TP LSP OAM packets is 
> > connected with an NNI port which is not able to support such OAM 
> > packets. For the case the G-ACH follows the LSP label stack entry 
> > header immediately (without intermediate GAL header), the 
> NNI port on 
> > the PE node will receive LSP packets with S=1 and 4-bit 
> nibble=0001. 
> > This port will not know what to do with it, and should as 
> such discard 
> > those LSP OAM packets as unknown and unexpected packets. I.e. what 
> > else could be done with those packets that do not have a next LSE 
> > header and are not IPv4/v6?
> > 
> > Looking forward to understand the rationale for the GAL 
> header in LSP 
> > OAM packets... If there is no real rationale for it, I propose to 
> > remove this GAL Header from those LSP OAM packets.
> > 
> > Regards,
> > Maarten
> > 
> > 
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp