Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Oct 2012 14:12:31 +0100

Eric,

Thank you for your review. To move the draft along
I have addressed the points you make as shown in line.

If my co-authors wish to amend this text, we will
do so during IETF LC and copy you on these amendments.

On 08/06/2012 21:28, Eric Gray wrote:
>
> My Last call review comments on draft-ietf-mpls-gach-adv-02:
>
> In general, this is a very well written draft that is nearly
> ready to publish.  There is one major issue that needs to be
> addressed.
>
> Major Issue:
>
> There is an important point that does not appear to have been
> made sufficiently clear in the IANA Considerations section.
>
> For the TLV types, I assume that the TLV type numbers (section
> 9.4) are intended to be allocated within the context of an
> application ID (allocated according to section 9.3).
>
> This is very much not clear.  In fact, reading section 9.4 as
> it now stands, it looks as if there is a single context for
> TLV IDs, that there are a maximum number of TLV IDs available
> of 255, and that five of these are used by the application in
> this draft.
>
> This seems odd, given that the number space for application IDs
> is from 0x000 to 0xFFFF.  It would seem that we anticipate we
> will have a lot of applications for this protocol, but not too
> many will actually need to say anything.
>
> Hence my assumption about the intent of the TLV type number
> space.
>
> Please clarify what you are really expecting from this TLV Type
> Registry.
In section 3 it says:
The Type field identifies the TLV Object and is scoped to a specific 
application; each application creates an IANA registry to track its Type 
values.

and in Section 4 it says:
The GAP supports several TLV objects related to its own operation via 
the Application ID 0x0000.

I have clarified that 9.4 refers to the GAP itself by amending
the registry title to be

"G-ACh Advertisement Protocol:  GAP TLV Objects (Application ID 0)"

>
> Minor Issue:
>
> In the second pargraph on page 4, I believe one can also use
> LLDP to discover the MAC address of an adjacent Ethernet peer.
> The authors mention this proposed GAP protocol standard can
> be used to exchange information similar to the use of LLDP,
> and then follows this immediately with a special case to find
> out an adjacent peer's MAC address in the case where IP isn't
> supported - using GAP.
>
> Have the authors given any thought to the possibility that the
> fact that IP is not supported may be attributable to the fact
> that Ethernet _is_ supported for L2 peer-to-peer exchanges,
> including LLDP?  IMO, this makes the "special case" not so
> much so.
>
> I think - given that there are a few things we know about this
> case (e.g. - both Ethernet and MPLS are presumed to apply), it
> would be useful to be clear about when it would be the case that:
>
> 1) IP is not present,
> 2) Ethernet is present,
> 3) Knowing the MAC address of an adjacent Ethernet entity is
>     needed, and
> 4) LLDP is not already used.
The GAP protocol can be used over a datalink other than
Ethernet (see section 1.1), including over an MPLS-TP
segment that is itself running over an MPLS-TP segment.

Whilst one use is to learn the MAC address, it has a number of purposes 
including announcing the configuration of the adverting node. Using a 
single protocol to announce the
MAC address along with other configuration information
seems to be a simplification compared to implementing
LLDP just for the MAC addresses.

The paragraph now says:

In networks based on the MPLS Transport Profile (MPLS-TP)
[RFC5921] that do not also support IP, the normal  protocols used to 
determine the Ethernet address of an adjacent MPLS node, such as the 
Address Resolution Protocol [RFC0826]
and IP version 6 Neighbor Discovery [RFC4861] are not
available. The G-ACh advertisement protocol can be used to discover the 
Ethernet MAC addresses of MPLS-TP nodes lacking IP capability 
[I-D.ietf-mpls-tp-ethernet-addressing]. Where it is anticipated that the 
sole purpose of the GAP will be to provide Ethernet MAC address 
learning, the use of LLDP SHOULD be considered.

>
> NIT:
>
> I find the phrase "a primary purpose" somewhat jarring in the
> Introduction.  Is there more than one "primary" purpose?
> Perhaps "One key" as opposed to "A primary"?
s/A primary purpose/ An important use/

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Oct 2012 16:17:20 +0100

On 08/06/2012 22:16, Eric Gray wrote:
>
> My Last Call comments on draft-ietf-mpls-tp-ethernet-addressing-01
>
> In general, this draft is nearly ready for publishing as an RFC.
> There are issues the working group and authors should consider.
>
> Major Issue:
>
> This is listed here because I am uncertain of the degree to which
> this may be a major or minor issue.
>
> The issue is with the inclusion of MTU as a discoverable parameter
> (Section 4).
>
> One reason for using a protocol other than LLDP to discover the
> Ethernet MAC address of an adjacent LSR, is where a physical link
> may include one or more intermediate bridges.
>
> If this is the case, and LLDP is not in use, then the MTU of the
> Ethernet end-stations (the peer/adjacent LSRs) may not be useful,
> since the intervening bridges could conceivably have a lower MTU.
Well, there may be pt-pt Ethernet switches, but there should
never be an Ethernet bridge in an MPLS-TP path, since
MPLS-TP is defined to be non-merging.

MTU may be useful on a PT-PT direct link, but I am not sure
what can be done in the other case other than to use the MTU
field as an upper bound in an MTU discovery process.

We could define an MTU discovery/verification application
at a later date if this was needed.

>
> Minor Issues:
>
> IANA Considerations -
>
> Why do the authors create yet another registry for IANA to maintain,
> instead of using TLVs (with type numbers taken from the regitry that
> was created in the GAP specification - from which this draft already
> takes a new application identifier)?
That is the design we have proposed - one registry per application.
Note the T size is 256, and thus we would need sub-TLVs if we
did not do that, and the sub-TLVs would need their own registries
so this is awash.
>
> This appears to set a very nasty precedent: each new application ID
> specified from an IANA registry may establish a new registry.  Does
> IANA have the head-room for this?
I think IANA will be fine with this. They will comment at IETF LC
if there is a problem, but I don't anticipate any issue.
>
> NITs:
>
> IANA Considerations -
>
> Not sure why section 6.1 is included.  There is no action required
> of IANA here, AFAICT.  Minimally, the authors should explicitly
> state that no further action is required from IANA by this section.
It provides traceability back to this RFC.

It says " IANA has allocated..." so IANA will see they have no actions.

- Stewart
>
> --
> Eric Gray
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, May 29, 2012 11:00 PM
> To: [email-masked]; MPLS-TP ad hoc team
> Subject: [mpls] wg last call on gach-adv and ethernet-addressing drafts
>
> Working Group,
>
>
> This is to start a two week working group last call on two drafts:
>
> - draft-ietf-mpls-gach-adv-02; and
> - draft-ietf-mpls-tp-ethernet-addressing-01
>
> Please send comments to the mpls working group list.
>
> The working group last call ends June 15, 2012.
>
>
> Thanks, Loa
>
> (as MPLS WG co-chair)
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Eric Gray <[email-masked]>
Date: Mon, 22 Oct 2012 15:31:14 +0000

Stewart,

	With the exception of one (probable) typo in your response (not your actual proposed text)
- where you say "adverting" and probably mean "advertising" - I am fine with your proposals.

	I had missed the text that describes the scoping of TLV types by application.

	I have one follow on question - which may or may not require clarification in the existing text.
In the text that describes the scoping of TLV object types, there are possibly two areas in which this
text may require further clarification:

1) Should the text suggest the creation of a registry for an application that does not immediately
     require TLV types, or should this be left to later work that adds these types?  I suspect that the
     best approach would be to say that a TLV type registry needs only to be created if the TLV types
     are explicitly defined in the document - but you may feel that this is "micro-management."

2) Is there any value in suggesting a specific template - based on this document (for the sake of 
     uniformity in IANA management of TLV type spaces for those applications requiring application-
     specific TLVs).  Again, this might be a form of micromanagement.

	Thanks for addressing my comments!

--
Eric

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Monday, October 22, 2012 9:13 AM
To: Eric Gray
Cc: Loa Andersson; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts
Importance: High

Eric,

Thank you for your review. To move the draft along I have addressed the points you make as shown in line.

If my co-authors wish to amend this text, we will do so during IETF LC and copy you on these amendments.

On 08/06/2012 21:28, Eric Gray wrote:
> In general, this is a very well written draft that is nearly ready to 
> publish.  There is one major issue that needs to be addressed.
>
> Major Issue:
>
> There is an important point that does not appear to have been made 
> sufficiently clear in the IANA Considerations section.
>
> 9.4) are intended to be allocated within the context of an application 
> ID (allocated according to section 9.3).
>
> This is very much not clear.  In fact, reading section 9.4 as it now 
> stands, it looks as if there is a single context for TLV IDs, that 
> there are a maximum number of TLV IDs available of 255, and that five 
> of these are used by the application in this draft.
>
> This seems odd, given that the number space for application IDs is 
> from 0x000 to 0xFFFF.  It would seem that we anticipate we will have a 
> lot of applications for this protocol, but not too many will actually 
> need to say anything.
>
> Hence my assumption about the intent of the TLV type number space.
>
In section 3 it says:
The Type field identifies the TLV Object and is scoped to a specific application; each application creates an IANA registry to track its Type values.

and in Section 4 it says:
The GAP supports several TLV objects related to its own operation via the Application ID 0x0000.

I have clarified that 9.4 refers to the GAP itself by amending the registry title to be

>
> Minor Issue:
>
> In the second pargraph on page 4, I believe one can also use LLDP to 
> discover the MAC address of an adjacent Ethernet peer.
> The authors mention this proposed GAP protocol standard can be used to 
> exchange information similar to the use of LLDP, and then follows this 
> immediately with a special case to find out an adjacent peer's MAC 
> address in the case where IP isn't supported - using GAP.
>
> Have the authors given any thought to the possibility that the fact 
> that IP is not supported may be attributable to the fact that Ethernet 
> _is_ supported for L2 peer-to-peer exchanges, including LLDP?  IMO, 
> this makes the "special case" not so much so.
>
> I think - given that there are a few things we know about this case 
> (e.g. - both Ethernet and MPLS are presumed to apply), it would be 
> useful to be clear about when it would be the case that:
>
> 1) IP is not present,
> 2) Ethernet is present,
The GAP protocol can be used over a datalink other than Ethernet (see section 1.1), including over an MPLS-TP segment that is itself running over an MPLS-TP segment.

Whilst one use is to learn the MAC address, it has a number of purposes including announcing the configuration of the adverting node. Using a single protocol to announce the MAC address along with other configuration information seems to be a simplification compared to implementing LLDP just for the MAC addresses.

The paragraph now says:

In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] that do not also support IP, the normal  protocols used to determine the Ethernet address of an adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery [RFC4861] are not available. The G-ACh advertisement protocol can be used to discover the Ethernet MAC addresses of MPLS-TP nodes lacking IP capability [I-D.ietf-mpls-tp-ethernet-addressing]. Where it is anticipated that the sole purpose of the GAP will be to provide Ethernet MAC address learning, the use of LLDP SHOULD be considered.

- Stewart

---

From: Eric Gray <[email-masked]>
Date: Mon, 22 Oct 2012 15:45:48 +0000

Stewart,

                There is an odd-ball "Ethernet Bridge" that may appear in some circumstances where
an operator may also chose to use MPLS-TP.  That "odd-ball" bridge is called a Two-Port MAC
Relay and corresponds close to what the MEF defines as a "NID" (network interface device).

                Where an operator may choose to use both is (possibly?) at the E-NNI between two
separately maintained service domains that are both owned by the same operator.

                If this were the case, it seems likely that the NID may re-encapsulate the frames it
forwards in one direction or the other, or may simply use a different technology that has a
subtly different native MTU (e.g. - as an adaptation, between different network types).

                One thing people tend to forget is that bridges are truly meant to be transparent.

--
Eric

From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, October 22, 2012 11:17 AM
To: Eric Gray
Cc: Loa Andersson; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing drafts
Importance: High

Major Issue:

(Section 4).

Minor Issues:

IANA Considerations -

NITs:

IANA Considerations -

- Stewart

--

Eric Gray

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Loa Andersson

To: [email-masked]<mailto:[email-masked]>; MPLS-TP ad hoc team

Working Group,

Thanks, Loa

(as MPLS WG co-chair)

--

---

From: Eric Gray <[email-masked]>
Date: Mon, 22 Oct 2012 16:08:49 +0000

Stewart,

                On the IANA allocation, this is a subtle issue, but is unlikely to be a problem.

                As you know, IANA is occasionally asked to pre-allocate code points.  This
process - as I understand it - is different from an actual allocation in that (AFAIK)
the allocation is not actually made in the registry but is reserved in IANA's notes
somewhere.

                Should it be made clear which case this allocation is?  I suspect that IANA
can figure that out, though, so it is not a big deal...

--
Eric

Major Issue:

(Section 4).

Minor Issues:

IANA Considerations -

NITs:

IANA Considerations -

- Stewart

--

Eric Gray

-----Original Message-----

Working Group,

Thanks, Loa

(as MPLS WG co-chair)

--

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Oct 2012 18:02:38 +0100

Hi Eric

Early allocation is a well known process and IANA annotate the
registry entry accordingly.

In particular they set a death date for the allocation and
this is visible in the registry.

Stewart

On 22/10/2012 17:08, Eric Gray wrote:
> process – as I understand it – is different from an actual allocation 
> in that (AFAIK)
>
> can figure that out, though, so it is not a big deal…
>
> --
>
> Eric
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* Monday, October 22, 2012 11:17 AM
> *To:* Eric Gray
> *Cc:* Loa Andersson; 
> [email-masked]; [email-masked]; 
> MPLS-TP ad hoc team
> *Subject:* Re: [mpls] wg last call on gach-adv and ethernet-addressing 
> drafts
> *Importance:* High
>
> From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of Loa Andersson
> To:[email-masked]  <mailto:[email-masked]>; MPLS-TP ad hoc team

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Oct 2012 18:11:19 +0100

Eric

The advertized MTU parameter will be the MTU parameter that
the operator configured at the TX end, so regardless of
whether we are running GAP we have a problem if an MTU reducing
node is introduced in the path.

The MPLS-TP design assumes that no one is going to configure
this sort of transparent bottleneck in the path and currently
has no way to detect it. Does Y.1731 detect this sort of problem?

If you seriously think we need to do MTU discovery, presumably
to report up to the management system - since we can't
do much about it at the PE, we can design an application to detect
it. However I think we need to confident that it is a real problem
and that a solution would be deployed.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Oct 2012 18:18:11 +0100

Hi Eric,

I think that (for the right reasons) you are trying to help IANA, but 
they have a well oiled process for this, and it is best to leave them to 
decide what is best practice  in each case.

On 22/10/2012 16:31, Eric Gray wrote:
>       require TLV types, or should this be left to later work that adds these types?
I think that it should be a case of first TLV creator registers the 
registry.

>   I suspect that the
The right thing is to let the authors (of the new work), IANA and the 
IESG cause the  right thing to happen. The latter two groups are well 
rehearsed on how to best approach registries.

- Stewart

---

From: t.petch <[email-masked]>
Date: Tue, 23 Oct 2012 13:05:19 +0100

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: "Eric Gray" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>; "MPLS-TP ad hoc team" <[email-masked]>
Sent: Monday, October 22, 2012 6:02 PM
Subject: Re: [mpls] wg last call on gach-adv and ethernet-addressing
drafts

Hi Eric

<tp>

All as decribed in RFC4020.  Interestingly, that specifies that
" IANA makes an allocation from the appropriate registry, marking it
      as "temporary", valid for a period of one year from the date of
      allocation.  The date of allocation should also be recorded in the
      registry and made visible to the public."
and
"   In particular, it is not IANA's responsibility to track the status
of
   allocations, their expiration, or when they may be re-allocated.
"

What you can see, in, for example, the MPLS registries, is
"TEMPORARY - expires 2012-01-20"
so IANA have not exactly put in the date of allocation, but equally, it
is not up to them to take any further action.

Tom Petch

Stewart

On 22/10/2012 17:08, Eric Gray wrote:
> From:[email-masked]  <mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Loa Andersson

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 23 Oct 2012 14:11:48 +0100

Yes,

IANA record the death date and it is up to the WGC to extend that.
One extension is allowed and then the allocation is supposed
to expire.

My practical experience however is that the IETF "does the
right thing" when it comes to deployed expired early allocations.

Stewart

On 23/10/2012 13:05, t.petch wrote:
> .